Theory Pill on Killers Openers, User Pilots Management and Risk Management
Historial de versiones
| Versión | Fecha | Diferencia entre versiones |
|---|---|---|
| 1.0 | 2024-02-29 | Versión inicial de los apuntes que se han sacado de los vídeos de teoría |
1. Killer Openers
El concepto de "killer opener" en presentaciones se refiere a una apertura o inicio muy poderoso y efectivo que capta inmediatamente la atención de la audiencia. El objetivo de un "killer opener" es enganchar al público desde el primer momento, estableciendo un tono emocionante o intrigante que los motive a querer escuchar el resto de la presentación. Esta técnica es crucial porque los primeros segundos de una presentación son fundamentales para generar interés y compromiso.
| Inicio efectivo |
|---|
 |
2. Risk Management
La gestión de riesgos generalmente sigue cuatro etapas:
- Identificación de riesgos
- Analizarlos y priorizarlos
- Evitarlos y mitigarlos
- Monitorizarlos
2.1 Identificación de riesgos
El proceso de identificación de riesgos puede comenzar con un brainstorm de ideas de todos los miembros del equipo.
Podemos clasificarlos entre riesgos de estimación, técnicos, requisitos y organizacionales. También existen clasificaciones más genéricas como: internos, externos, internos-externos.
Lo verdaderamente interesante no es clasificar si no identificar los riesgos. Algunos factores de riesgo son: el grado de innovación tecnológica, requisitos cambiantes, arquitectura no planificada, falta de testing adecuado (especial atención al rendimiento), baja calidad del código, deadlines muy agresivos, baja productividad, escasa documentación, falta de compromiso, falta de comunicación, bus factor (dependencia de ciertos miembros del equipo. Qué ocurre si faltan), aspectos de financiación y presupuesto.
2.2 Análisis de riesgo y priorización
Una vez identificados los factores, tenemos que darnos cuenta de cuáles son realmente problemas potenciales: ¿Qué probabilidad tienen de ocurrir? ¿Qué impacto tendrían? Asignar un valor a esos dos aspectos nos permite calcular (multiplicar ambos valores) y priorizar cada riesgo.
2.3 Evitar y mitigar riesgos
Si existe un factor que verdaderamente presenta un riesgo importante, quizás debe replantearse el alcance del proyecto.
Se deben definir planes de contingencia para cada uno de los riesgos identificados. Estos planes deben tener un nivel de detalle adecuado, que indique exactamente cómo proceder dado el caso.
2.4 Monitorización de riesgos
Los riesgos deben estar en constante monitorización. Debe analizarse la situación actual y acudir a los planes de contingencia en caso de enfrentar alguno de los problemas registrados y llevar a cabo acciones correctivas que mitiguen el efecto de dichos problemas. Es importante comprobar que la acción correctiva está siendo efectiva. Para ello se deben plantear objetivos y medir la efectividad de la acción para alcanzar esos objetivos. En caso de no conseguir resultados, debemos cambiar la acción correctiva.
3 User Pilot
Una gestión adecuada de usuarios piloto debe seguir los siguientes pasos:
- Seleccionar participantes
- Una buena selección de los escenarios de prueba
- Planificación de las pruebas y encuestas de feedback
- Plan de comunicación con los usuarios piloto
- Fomentar la integración de los usuarios pilotos
- Sacar conclusiones
3.1 Seleccionar participantes
Es preciso hacer una buena selección de los usuarios pilotos. Deben ser parte del público objetivo de la funcionalidad que ofrece la solución propuesta, y dentro de ese espectro, debe ser un público diverso que pueda ofrecer diferentes perspectivas.
3.2 Seleccionar escenarios de prueba
Se deben definir claramente los escenarios de prueba que se ofrecerán a los usuarios pilotos. Existen escenarios de prueba dirigidos y no dirigidos. El tipo de escenario elegido dependerá de la característica del sistema que queremos evaluar.
3.3 Planificación de las pruebas y encuestas de feedback
Una vez realizado lo anterior, se deben definir los tiempos. Se debe elaborar una planificación en la que se indique el periodo de prueba de la funcionalidad a evaluar.
Además, se debe elaborar una encuesta para recoger el feedback de los usuarios piloto. Es fundamental hacer preguntas adecuadas (evitar preguntas complejas), definir métricas específicas de éxito (ej. establecer rangos de puntuación que nos indiquen el grado de satisfacción de los usuarios), registrar la tendencia de puntuación de los diferentes usuarios (podemos analizar si la experiencia de un usuario mejora o empeora a lo largo del desarrollo).
3.4 Plan de comunicación con los usuarios piloto
Siempre debemos estar disponibles para el feedback de los usuarios piloto. Para ello debemos establecer canales claros y simples (ej. helpdesk como iTop) que fomenten esa comunicación.
Se deben dejar claro los tiempos de feedback y las fechas límite.
3.5 Fomentar la integración de los usuarios pilotos
Si no se incentiva al usuario piloto, si no se le presenta un beneficio, no va a realizar el proceso con ánimo, no va a tener ningún incentivo para hacerlo. Debe elaborarse un plan original que incentive al usuario piloto a colaborar activamente con la prueba del producto.
3.6 Sacar conclusiones
Todo el feedback que proporcionan los usuarios pilotos debe ser priorizado y analizado para establecer que se puede llevar a cabo y que no. Pero, en cualquier caso, siempre se debe hacer sentir al usuario que se ha tenido en cuenta su feedback.
3.7 Pilot testing vs Beta testing
